chore: updated scim 409 conflict error details#2501
Conversation
| - If the user already exists within the project or organization, the provisioning may fail with a 409 conflict error. This is | ||
| because the SCIM server cannot modify existing users that have not been provisioned via SCIM. In this case, you need to manually | ||
| delete the user first. | ||
| - If a user already exists within the same organization, SCIM provisioning will update the user using the configured data mapper. |
There was a problem hiding this comment.
It sounds like the original limitation (above) no longer exists! That is, an existing user in now updated and there is no 409 error. So it makes sense to delete the limitation above.
| because the SCIM server cannot modify existing users that have not been provisioned via SCIM. In this case, you need to manually | ||
| delete the user first. | ||
| - If a user already exists within the same organization, SCIM provisioning will update the user using the configured data mapper. | ||
| However, if the user exists in a different organization, provisioning may fail with a 409 Conflict error. In this case, you must |
There was a problem hiding this comment.
I don't understand how this is a limitation! A SCIM provisioning map is per organization. So why are we talking about the 'same' or a 'different' organization. Either the identity exists in the organization or it doesn't. If it doesn't exist, isn't it created? If it does exist, isn't it updated? That is the expected behavior. Why are we saying they should delete a user from one organization and add them to a different one? (That would mean there was an expectation that the mapping would know which organization the identity should be in and update it there.)
There was a problem hiding this comment.
@unatasha8 The mapping is per org, but identity resolution isn’t — the system checks for existing users globally. So if the same identity already exists in another org (or without an org), SCIM can’t create or reassign it automatically, which is why you get a 409.
unatasha8
left a comment
There was a problem hiding this comment.
See comments. The text is confusing.
| - If the user already exists within the project or organization, the provisioning may fail with a 409 conflict error. This is | ||
| because the SCIM server cannot modify existing users that have not been provisioned via SCIM. In this case, you need to manually | ||
| delete the user first. | ||
| - If a user already exists within the same organization, SCIM provisioning will update the user using the configured data mapper. |
There was a problem hiding this comment.
| - If a user already exists within the same organization, SCIM provisioning will update the user using the configured data mapper. | |
| - If a user already exists within the targeted organization, SCIM provisioning will update the user using the configured data mapper. |
| because the SCIM server cannot modify existing users that have not been provisioned via SCIM. In this case, you need to manually | ||
| delete the user first. | ||
| - If a user already exists within the same organization, SCIM provisioning will update the user using the configured data mapper. | ||
| However, if the user exists in a different organization, provisioning may fail with a 409 Conflict error. In this case, you must |
There was a problem hiding this comment.
| However, if the user exists in a different organization, provisioning may fail with a 409 Conflict error. In this case, you must | |
| However, if the user exists in a different organization, or is not in any organization, provisioning may fail with a 409 Conflict error. In this case, you must |
| delete the user first. | ||
| - If a user already exists within the same organization, SCIM provisioning will update the user using the configured data mapper. | ||
| However, if the user exists in a different organization, provisioning may fail with a 409 Conflict error. In this case, you must | ||
| either: manually delete the existing user, or move the user into the target organization before retrying provisioning. |
There was a problem hiding this comment.
| either: manually delete the existing user, or move the user into the target organization before retrying provisioning. | |
| either: manually delete the existing user or move the user into the targeted organization, and then retry provisioning. |
unatasha8
left a comment
There was a problem hiding this comment.
Made updates, please accept, the LGTM
Since the PR is already merged you'll have to do this in a new PR. |
Related Issue or Design Document
Checklist
If this pull request addresses a security vulnerability,
I confirm that I got approval (please contact security@ory.com) from the maintainers to push the changes.
Further comments